Skip to content

feat(cryptography): add Wycheproof verification tests for Ed25519#3771

Open
erenyegit wants to merge 1 commit into
commonwarexyz:mainfrom
erenyegit:feat/wycheproof-ed25519
Open

feat(cryptography): add Wycheproof verification tests for Ed25519#3771
erenyegit wants to merge 1 commit into
commonwarexyz:mainfrom
erenyegit:feat/wycheproof-ed25519

Conversation

@erenyegit
Copy link
Copy Markdown

This PR addresses #329 for the Ed25519 primitive. Follow-up PRs will add the same pattern for secp256r1 and bls12381.

What this adds

A self-contained Project Wycheproof verifier-conformance test suite for Ed25519. Vectors are sourced from testvectors_v1/ed25519_test.json pinned at commit 6d9d6de30f02e229dfc160323722c3ddac866181 (150 cases across 77 groups).

Three new tests live in cryptography/src/ed25519/wycheproof.rs:

  • wycheproof_valid_vectors_verify — every Wycheproof valid vector must verify under ZIP215.
  • wycheproof_invalid_vectors_rejected — every Wycheproof invalid vector must be rejected, except entries on the documented ZIP215_DEVIATIONS allow-list. This is the workhorse negative test: 62 attack vectors asserting "this signature shouldn't verify and doesn't."
  • vector_count_matches_upstream — guards against accidental truncation of the auto-generated vector array.

Design choices

No new dependencies. Per CONTRIBUTING.md, vectors are preprocessed offline by cryptography/test_vectors/wycheproof/regenerate.py into a const VECTORS: &[Vector] array in wycheproof_vectors.rs. The original JSON is committed alongside the generated .rs so reviewers can audit either form, and the regen script pins the upstream commit so the data is fully reproducible.

ZIP215-aware. Commonware's verifier follows ZIP215, which is intentionally more permissive than RFC 8032 about non-canonical encodings. Some Wycheproof "invalid" cases are ZIP215-accepted by design; the test framework handles this via a documented ZIP215_DEVIATIONS allow-list keyed by tcId, each entry citing its deviation class (non-canonical R, low-order point, etc.). At the pinned commit the list is empty — verified empirically: 62/62 invalid vectors are rejected by the ZIP215 verifier.

Direct core::VerificationKey::verify path. Tests bypass the namespaced Verifier::verify (which union_unique-prefixes the message) to feed raw Wycheproof messages into the production verification routine.

How tested

  • cargo test -p commonware-cryptography --lib ed25519::wycheproof → 3/3 pass
  • cargo clippy -p commonware-cryptography --tests --no-deps -- -D warnings → clean
  • rustfmt --edition 2021 --check on all touched files → clean
  • just pre-pr → 5460/5460 tests pass, exit 0

Note: my local workspace target/ couldn't hold every test binary at full debug info, so just pre-pr was run with CARGO_PROFILE_*_DEBUG=0. The flag affects only artifact size, not correctness — CI will run in its default config.

Files

Path Lines Purpose
cryptography/src/ed25519/mod.rs +4 Declare the two new test modules
cryptography/src/ed25519/wycheproof.rs +186 Test runner, ZIP215_DEVIATIONS framework, doc comment
cryptography/src/ed25519/wycheproof_vectors.rs +3,184 Auto-generated VECTORS constant
cryptography/test_vectors/wycheproof/ed25519_test.json +3,327 Vendored vectors at pinned commit
cryptography/test_vectors/wycheproof/regenerate.py +185 Regen script with WYCHEPROOF_COMMIT constant

Scope follow-ups

This PR covers Ed25519. Follow-up PRs will add Wycheproof suites for secp256r1 and bls12381 reusing the same offline-regeneration pattern.

Loads real Project Wycheproof test vectors from ed25519_test.json pinned at upstream commit 6d9d6de30f02e229dfc160323722c3ddac866181 and runs them through the production verifier (core::VerificationKey::verify). The raw core path is used deliberately to bypass Verifier::verify's namespace prefixing, which would invalidate every upstream vector.

To stay within CONTRIBUTING.md's "no new external dependency" rule, the JSON is preprocessed offline by regenerate.py into a &[Vector] constant in wycheproof_vectors.rs; the runtime test code therefore has zero JSON parsing burden and zero new dependencies.

ZIP215 deviations from strict RFC 8032 are tracked in an explicit ZIP215_DEVIATIONS allow-list; at the pinned commit the list is empty (every Wycheproof-invalid vector is also rejected by ZIP215).

Refs commonwarexyz#329.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant